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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 
This document defines a RADIUS (Remote Authentication Dial In User 
Service) attribute that carries an IPv6 prefix that is to be 


delegated to the user. This attribute is usable within either RADIUS 
or Diameter. 
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Les 


Introduction 


This document defines the Delegated-IPv6-Prefix attribute as a RADIUS 
[1] attribute that carries an IPv6 prefix to be delegated to the 
user, for use in the user’s network. For example, the prefix ina 
Delegated-IPv6-Prefix attribute can be delegated to another node 
through DHCP Prefix Delegation [2]. 


The Delegated-IPv6-Prefix attribute can be used in DHCP Prefix 
Delegation between the delegating router and a RADIUS server, as 
illustrated in the following message sequence. 


Requesting Router Delegating Router RADIUS Server 


=SOLLGLe-=SSsSsSSsne- > 


“REQUCSIE SSeS SS aS > 
| |<--Accept (Delegated-IPv6-Prefix)- | 
|<--Advertise (Prefix)-| 
| -Request (Prefix) ---->| | 
|<--Reply (Prefix)----- | | 


DHCP PD RADIUS 


The Framed-IPv6-Prefix attribute [4] is not designed to support 
delegation of IPv6 prefixes to be used in the user’s network, and 
therefore Framed-IPv6—-Prefix and Delegated-IPv6-Prefix attributes may 
be included in the same RADIUS packet. 


Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [3]. 
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3. Attribute Format 
The format of the Delegated-IPv6-Prefix is: 


0 1 2 3 
Ook “2.3 A S 67. <8 9 0 ak (2 3 A4 GOD, BP 9 0-1 23 A DS 67 28. 9° Oo 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Reserved | Prefix-Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Prefix 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Prefix 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Prefix 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Prefix 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


123 for Delegated-IPv6-Prefix 
Length 


The length of the entire attribute, in bytes. At least 4 (to 
hold Type/Length/Reserved/Prefix-Length for a 0-bit prefix), 

and no larger than 20 (to hold Type/Length/ Reserved/Prefix- 

Length for a 128-bit prefix) 


Reserved 
Always set to zero by sender; ignored by receiver 
Prefix-Length 
The length of the prefix being delegated, in bits. At least 
0 and no larger than 128 bits (identifying a single IPv6 
address) 
Note that the prefix field is only required to be long enough to hold 
the prefix bits and can be shorter than 16 bytes. Any bits in the 
prefix field that are not part of the prefix MUST be zero. 
The Delegated-IPv6-Prefix MAY appear in an Access-Accept packet, and 
can appear multiple times. It MAY appear in an Access-Request packet 


as a hint by the NAS to the server that it would prefer these 
prefix(es), but the server is not required to honor the hint. 
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The Delegated-IPv6-Prefix attribute MAY appear in an Accounting- 
Request packet. 


The Delegated-IPv6-Prefix MUST NOT appear in any other RADIUS 
packets. 


4. Table of Attributes 


The following table provides a guide to which attributes may be found 
in which kinds of packets, and in what quantity. 


4+------------------ $5 5 = + 
| Request Accept Reject Challenge Accounting # Attribute | 
| Request | 
| 0+ 0+ 0 0 0+ 123 Delegated-IPv6- ć | 
| Prefix | 
4+-------------------- -- + - - 5 = + 


The meaning of the above table entries is as follows: 
0 This attribute MUST NOT be present. 
0+ Zero or more instances of this attribute MAY be present. 
0-1 Zero or one instance of this attribute MAY be present. 
1 Exactly one instance of this attribute MUST be present. 
1+ One or more of these attributes MUST be present. 


5. Diameter Considerations 


When used in Diameter, the attribute defined in this specification 
can be used as a Diameter AVP from the Code space 1-255, i.e., RADIUS 
attribute compatibility space. No additional Diameter Code values 
are therefore allocated. The data types of the attributes are as 
follows: 


Delegated-IPv6-Prefix OctetString 


The attribute in this specification has no special translation 
requirements for Diameter to RADIUS or RADIUS to Diameter gateways, 
i.e., the attribute is copied as is, except for changes relating to 
headers, alignment, and padding. See also RFC 3588 [5], Section 4.1, 
and RFC 4005 [6], Section 9. 


The text in this specification describing the applicability of the 
Delegated-IPv6-Prefix attribute for RADIUS Access-Request applies in 
Diameter to AA-Request [6] or Diameter-EAP-Request [7]. 


The text in this specification describing the applicability of the 


Delegated-IPv6-Prefix attribute for RADIUS Access-Accept applies in 
Diameter to AA-Answer or Diameter-EAP-Answer that indicates success. 
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8. 


8. 


The text in this specification describing the applicability of the 
Delegated-IPv6-Prefix attribute for RADIUS Accounting-Request applies 
to Diameter Accounting-Request [6] as well. 


The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are: 


4--------------------- + 
| AVP Flag rules | 
----+----- 4+----+4+----- |---- + 
AVP | |SHLD| MUST | 
Attribute Name Code Value Type |MUST| MAY | NOT| NOT|/Encr| 


| | 
| + 

Delegated-IPv6- 123 OctetString| M | P 
Prefix | | 
| + 


IANA Considerations 


IANA assigned a Type value, 123, for this attribute from the RADIUS 
Attribute Types registry. 


Security Considerations 
Known security vulnerabilities of the RADIUS protocol are discussed 
in RFC 2607 [8], RFC 2865 [1], and RFC 2869 [9]. Use of IPsec [10] 


for providing security when RADIUS is carried in IPv6 is discussed in 
RFC 3162. 


Security considerations for the Diameter protocol are discussed in 
RFC 3588 [5]. 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
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this document or the extent to which any license under such rights 
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